The Portal market is one of the fastest growing markets of computer software. A Portal in the present invention may be defined as an application which provides a secure, single point of interaction with diverse information, business processes, and people, personalized to a user's needs and responsibility. The huge demand drives rapid development of new technologies by different Portal vendors in order to place their products in good market positions. Therefore, it isn't surprising that Portals already ran through different evolutionary phases. In a first step, the Portals were mainly used as access points to different information sources and content was solely chosen by the Portal operator. Soon after that, the users got the possibility to influence the displayed contents and customization was born. This was a great step forward because the user was able to select information according to personal interests and to find relevant information faster. The potential of such user customized information delivery was also interesting in the field of intra business information distribution and the first business or corporate Portals were introduced.
The ongoing evolution also left its footprint in the architecture of Portal products. At first, Portal-like products were delivered as pre-packaged applications that could be installed out of the box and included standard applications, which provided all functionality of the Portal. Step by step, new applications were needed and the vendors extended their products in order to satisfy those requirements. Due to the usage of proprietary designs, the vendors were the only ones, who added new functionality to their Portals and therefore the success of a Portal was closely related to the applications it brought along. This led to the decomposition of the monolithic structures and to the creation of Portal frameworks.
The Portal products offered today employ Portal architectures where a Portal itself only implements standard functionality like security, authorization, authentication, aggregation, caching, user management, enrollment, rendering and so on and provides the infrastructure for application components. This architecture includes APIs for the integration of applications so that applications from different partners can be used as long as they match the Portal product's API. In the Portal environment, these applications are typically called Portlets.
Portlets are pluggable components that can be added to Portals and are designed to run inside a Portal's Portlet container. Portlets may provide different functions ranging from simple rendering of static or dynamic content to application functions such as e-mail, calendar, etc. Portlets are invoked indirectly via the Portal application and produce content that is suited for aggregation in larger pages, e.g. Portlets should produce mark-up fragments adhering guidelines that assure that the content generated by different Portlets can be aggregated into one page. Typically, Portlets run on the Portal-Server, processing input data and rendering content locally. Often, the content for Portlets which are displayed very often is cached locally to improve response times, performance and scalability of Portals. While local Portlets typically provide short response times, this approach is not well suited to enable dynamic integration of business applications and information sources into Portals.
More and more local Portlets running in a Portal environment using Web-Services provided by Web-Service-Provider. Web-Services may be defined as providing existing or software components into a service-oriented architecture (SOA).
In contrast to these major changes, the used customization concepts haven't changed significantly. The biggest difference is that users nowadays choose Portlets from a list provided by the Portal administrator. However, there is no way to integrate whole page structures or page groups into a Portal or to manipulate the set of Portlets a page contains dynamically. But these features would allow for a variety of new Portal applications that would improve the usability of a Portal even more.
One example is remote content integration. Whole page groups or pages could be integrated from remote Portals.
Another example is integration of workflow with Portals. Workflow may be defined in the present invention as an application which provides automation of a business process, in whole or in part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules. While workflow provides means to pass information and tasks to persons, a Portal provides personalized presentation of this information and the applications required to perform the tasks. The combination of these two technologies promises outstanding synergy.
Existing Workflow Systems use clients that manage lists containing work items, which represent work that have to be performed by the user. The Workflow System determines the users that are capable to perform the work and assigns work items to their lists. In case that there exist Portlets that can process these tasks, these Portlets could be dynamically added or removed to a page and could make the client obsolete to some degree.
It is object of the present invention to provide a Portal mechanism that allows dynamic integration of presentation structures into Portal based on states of Internal or External Systems.
It is further object of the present invention to provide a mechanism that allows dynamic integration of workflow into a Portal.